home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group96a.txt / 000138_icon-group-sender _Tue Jun 18 12:57:40 1996.msg < prev    next >
Internet Message Format  |  1996-09-05  |  3KB
  1. Received: by cheltenham.cs.arizona.edu; Tue, 18 Jun 1996 13:13:45 MST
  2. Message-Id: <9606181957.AA24809@ cynic.org>
  3. To: Hamish Lawson <H.Lawson@tees.ac.uk>
  4. Cc: icon-group@cs.arizona.edu
  5. Subject: Re: Locking files 
  6. In-Reply-To: Your message of Tue, 18 Jun 1996 13:11:43 BST.
  7.              <31C69CFF.6292@tees.ac.uk> 
  8. Date: Tue, 18 Jun 1996 12:57:40 -0700
  9. From: Perry The Cynic <perry@sutr.cynic.org>
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11. Status: O
  12.  
  13. >> there is a cheap way of locking something
  14. >> globally used for ages: the *creation* of a special "lock" file
  15. >> just before entering the critical section (if it is absent,
  16. >> otherwise sleep/wait), and the destruction after.
  17.  
  18. > Is there not a small risk that in the time between some process finding 
  19. > that the lock file doesn't exist and creating this file, another process 
  20. > might also find that the lock file doesn't exist, thereby breaking the 
  21. > exclusivity mechanism.
  22.  
  23. For the "lockfile trick" to work between two "lockers", the operating
  24. service/system interface must provide "atomic create"; that is, "create
  25. this file if it doesn't exist, but fail if it does, atomically." All UNIXes
  26. (that I know of) allow this (the O_EXCL flag to the open() system call),
  27. and most other operating systems have equivalent functionality (even MS-DOS).
  28. On a system that does *not* have this feature, the lockfile trick is
  29. not (completely) safe.
  30.  
  31. Icon models its open() function on the UNIX fopen() routine, which
  32. (for historic reasons) does not *portably* provide access to the
  33. underlying O_EXCL open() flag. Thus, creating a lockfile using Icon's
  34. standard open() function is not (completely) safe. This is not really
  35. a failure of Icon, since it is supposed to provide *portable* access
  36. to whatever system it runs on -- some of which may not support atomic
  37. file creation at all.
  38.  
  39. There are other warts on the "simple" lockfile idea. If a process dies
  40. unexpectedly (say, killed by system crash or operator), a stale lockfile
  41. may be left behind. For a robust system, you must therefore encode
  42. extra information (e.g. the process id of the owner) to check for stale
  43. lockfiles and recover from them. That in turn is becoming quite system
  44. dependent (checking whether a process is alive, choosing timeout
  45. periods, etc.), not to mention interesting in the presence of network file
  46. systems.
  47.  
  48.   -- perry
  49. ---------------------------------------------------------------------------
  50. Perry The Cynic                                             perry@cynic.org
  51. To a blind optimist, an optimistic realist must seem like an Accursed Cynic.
  52. ---------------------------------------------------------------------------
  53.